This is the most trivial approach, and figured it was enough to start a concrete discussion rather than the abstract one over on the bug.

My main concern is that I think this approach makes it the config file that will be modified by pip config set --global …? And I'm not sure that's what we want...

My main concern is that I think this approach makes it the config file that will be modified by pip config set --global …

Indeed it is, and I don't like that, so I changed it to insert(0, sys.prefix) instead of .append().

Be careful here - we have both a local copy of appdirs and a vendored one, and I don't think they are consistently used. It's a mess that should be sorted at some point (probably by switching to just using the vendored one, which means patching appdirs will be something we'd want to avoid).

In my search of the current source tree, the vendored one is used once in the vendored pkg_resources, and not in pip's codebase itself. And the only function used in pip itself is one that doesn't exist in the vendored one at all, so I suspect we'd be better off removing the vendored one and keeping the fork.

Rerunning CI, and hopefully the macOS build won't fail with an HTTP timeout this time.

the vendored one is used once in the vendored pkg_resources

Ah, thanks, it looks like things have changed since I last looked. Sorry for the noise.

So it seems macOS doesn't like files.pythonhosted.org today, for some reason. I'll requeue the build next time I take a look, assuming there's no further discussion or changes needed before then.

So in terms of naming, I would consider this the "site config file", but that name is already used to mean global config files (and is already a list of files, which is why I added to that one). Suggestions?

Alternatively, make venv actually mean the current environment, regardless of whether it's a venv or not. Which basically means just removing the running_under_virtualenv() check.

As for the current approach, I've already stated that I'm okay with it, as well as suggested a renaming of venv in that case, modifying pip config in the appropriate manner to deprecate and rename functionality.

#5060 (comment)

suggested a renaming of venv

Did you suggest something to rename it to (which I can't find right now)? Or would you like to?

I personally like the name site, though that may be confusing in the codebase since all the functions for getting global paths are already called site. Otherwise, I like env (just drop the v). Do you have a preference?

(Obviously venv remains as an alias, and I can also add a bit more logic to make sure that it continues to fail if you're not in a virtual environment?)

@zooba I'd suggested ''changing the "venv" to "site" for pip config'' in the comment linked in my previous comment. I think we should, if we make this change (and do cleanups in the "locations" file too, for site vs global clarification, while we're doing that). That said, I do think we should first figure out if this is the change we want to make. :)

make venv actually mean the current environment, regardless of whether it's a venv or not. Which basically means just removing the running_under_virtualenv() check.

@dstufft and @pfmoore didn't seem very warm to this idea when I'd suggested this earlier, in the previously linked comment. I'm not sure how we'd address the concerns raised so I guess inputs from them would be most useful here.

Then I'll implement that change so it's concrete enough to argue about :)

My concern was about the fact that this was a request for special-case processing for conda. But as it's so simple to do, I don't really object to the change on a technical basis.

I added the test.

The if not file_options block already has a check for that - the order of handling there is "no options (use default), one option (use it), else raise". (Personally I prefer to put the error and early-return cases first so that you know you can stop reading there, but I chose not to reorder what was already here.)

This PR is just awaiting maintainer feedback/merge.

Ping @pypa/pip-committers (oh hey, I can annoy all of you at once ;) )

Thanks @zooba for working on this! :)

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.